home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 9720 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.9 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: malloc question
  5. Date: 12 Mar 1996 16:36:27 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4i4u9b$irt@solutions.solon.com>
  8. References: <4htonk$350@news.hklink.net> <AD69AACE9668D78B0@mcdiala09.it.luc.edu> <4i1kq3$2m0@solutions.solon.com> <AD6AFF6D9668E8DB7@mcdiala09.it.luc.edu>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <AD6AFF6D9668E8DB7@mcdiala09.it.luc.edu>,
  12. Verne Arase <VArase@varase.it.luc.edu> wrote:
  13. >In article <4i1kq3$2m0@solutions.solon.com>,
  14. >seebs@solutions.solon.com (Peter Seebach) wrote:
  15. > >>In this specific case, however, it _never_ hides an error. If malloc is
  16. > >>used in its standard context, we are simply coercing a slab of memory
  17. > >>aligned to the most stringent boundaries into a pointer of the desired
  18. > >>type.
  19.  
  20. > >Which does *nothing*, because void pointers always convert to the desired
  21. > >type silently and automatically.
  22.  
  23. >Provided you're not dealing with a pre-ANSI compiler.
  24.  
  25. Of course; this is comp.lang.c, not comp.lang.c-and-its-predecessors.
  26.  
  27. Unless explicitly described otherwise, code is assumed to be in C, not
  28. pre-ANSI C, GNU C, or whatever else.
  29.  
  30. > >Further, it *did* hide an error in the specific case; <stdlib.h> was not
  31. > >included, and there was no prototype in scope.
  32.  
  33. >Then that was what should have been said.
  34.  
  35. It's better to give a newbie the most general and useful advice, which is to
  36. avoid casts unless you're ver clear on what they're doing in a given case.
  37.  
  38. > >And you are _always_ redundant doing so, unless you're passing to a
  39. > >varaidic function or one with no prototype in scope.
  40.  
  41. >I had a pre-ANSI compiler which defined malloc as returning char *.
  42.  
  43. Cool.  I have a pre-ANSI compiler which thinks sprintf() returns a char *
  44. too, and for that matter, I used to have one which thought that a[i] and i[a]
  45. were different.
  46.  
  47. They're all broken.
  48.  
  49. > >char is not a signed quantity.  char is a quantity which may be signed or
  50. > >unsigned.
  51.  
  52. >Every implementation I've seen makes char signed.
  53.  
  54. And?  Every implementation I've ever used has 32 bit longs.  Shall we
  55. describe the C *language* as specifying that long is no more than 32 bits?
  56. Anyway, both of my Amiga C compilers have switches to select between signed
  57. and unsigned char at compile time.
  58.  
  59. > >It's a question of usage.  An unspecified short, int, or long is *always*
  60. > >signed, so it is clearly desireable for char to be signed.  EOF is
  61. > >negative, and the getc family all return unsigned char or EOF, so it is
  62. > >clearly desireable for char to be unsigned.
  63.  
  64. >While you'd probably want a short, int, or long to be signed, what's the
  65. >percentage of time you actually _want_ char to be signed? And what's the
  66. >percentage of time you gave a hoot whether you had a char * or an unsigned
  67. >char *?
  68.  
  69. Well, in the cases where I care at all, I want char to be signed.
  70. If I want an unsigned char, I say unsigned.  I like the consistency
  71. thing.
  72.  
  73. >As for the getc routines: don't have any C references here, but don't they
  74. >return an int?
  75.  
  76. Yes.  An int which is (character converted to unsigned char) or EOF.  In
  77. this context, it would be ideal if char were unsigned by default.
  78.  
  79. > >If you don't put in casts, you will get warnings for any conversion not
  80. > >normally correct.  This is helpful.
  81.  
  82. >Depends on the compiler.
  83.  
  84. >I've had IDEs where an uncasted pointer conversion just produced an error
  85. >and stopped the compile.
  86.  
  87. If it was a legit conversion, the IDE was broken.  If it wasn't, that's a good
  88. thing, a desireable behavior, and a feature.
  89.  
  90. Of course, many things with IDE's are really C++ compilers, not C compilers; if
  91. you use the wrong compiler for a program, that's your own problem.
  92.  
  93. -s
  94. -- 
  95. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  96. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  97. FUCK the communications decency act.  Goddamned government.  [literally.]
  98. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  99.